From: svermeul@suntzu.psg.datap.ca (Stephen Vermeulen)
Message-Id: <199603221828.LAA15178@alien.psg.datap.ca>
To: mui@sunsite.Informatik.RWTH-Aachen.DE
Subject: Re: Example of possible MUI rendering bug
X-Sun-Charset: US-ASCII
Resent-Message-Id: <"Ni-9t.0.Kt.j7lKn"@sunsite>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.DE
X-Mailing-List: archive/latest/743
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE
Content-Type: text
Content-Length: 2356
X-Lines: 66
Status: RO
> > Stefan,
> >
> > Here is source code and two executables that demonstrate the
> > two rendering bugs I posted to the mui-list about earlier
> > today. I suspect the problem might be something to do with
> > the overloading of the min-max function when I set up a
> > custom class.
> >
> > What I really want are listviews that BEHAVE like those in
> > the "muibug" executable (without the rendering errors), but
> > not like the "nomuibug" executable where the scrolling lists
> > do not expand to the full window size.
>
> Well, this really looks extremely buggy!
>
> Another thing: Have you ever tried to use a background picture for
> ListViews in the Settings? It looks rather nice, but when scrolling, only
> the part that actually HAS to scroll when no picture is used is scrolled.
> When a picture is present, the *whole* inner region of the ListView Object
> has to be scrolled.
>
> ___
> Ciao, LCS / / _______
> / /_/ ____/
> Thomas Schuerger
I discovered a fix for my problem, which might also solve your problem:
In the construction of the custom class I added:
MUIA_FillArea, TRUE,
and all the corruption problems went away.
Of course the MUI autodocs suggest that I should have added:
MUIA_FillArea, FALSE,
to get the desired effect:
NAME
MUIA_FillArea -- (V4 ) [IS.], BOOL
FUNCTION
Set this if you are a custom class and dont want area class to
clear your background during the DoSuperMethod() in your
draw method. Note that if you set this, your draw method
is responsible for filling every pixel of your objects
rectangle, otherwise some display trash will remain there.
I tried this and no change. So I think the autodocs
should read:
Set this if you are a custom class and DO want area class to
clear your background during the DoSuperMethod() in your
draw method. Note that if you DO NOT set this, your draw method
is responsible for filling every pixel of your objects
rectangle, otherwise some display trash will remain there.
(my changes are in CAPITALS).
I suspect that the Area class and possibly the ListView classes default to
MUIA_FillArea, FALSE. A fact that might be worth documenting.
Regards, Stephen
From: "Stefan Stuntz"
Date: Wed, 10 Apr 1996 23:27:45 +0100
X-Mailer: IntuiNews 1.3b Beta 7 (2.2.96)
Subject: Re: Updating an object
Message-Id: <81321049@magic.informatik.tu-muenchen.de>
Organization: Home of MUI
Resent-Message-Id: <"dMTj1.0.7Q1.Bm2Rn"@sunsite>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.DE
X-Mailing-List: archive/latest/1004
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE
Content-Type: text
Content-Length: 475
X-Lines: 13
Status: RO
Michal Kracik wrote in article <009A0A6B.E9D2C95A.13@cs.felk.cvut.cz>:
> I am afraid that MUIA_FixWidth is documented as "Init only" attribute
> (not Settable), so I thought (until now) that even this was not the correct
> way to do it.
Well, I usually only document attributes as set()able if they are really
completely aware of being set to a different value. MUIA_FixWidth, when
set, stores the new stuff but doesnt update the object accordingly.
--
Greetings, Stefan
From: "Stefan Stuntz"
Date: Tue, 16 Apr 1996 12:08:57 +0100
X-Mailer: IntuiNews 1.3b Beta 7 (2.2.96)
Subject: Re: MUIA_Background
Message-Id: <81321169@magic.informatik.tu-muenchen.de>
Organization: Home of MUI
Resent-Message-Id: <"-51Gl2.0.Jx1.68tSn"@sunsite>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.DE
X-Mailing-List: archive/latest/1071
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE
Content-Type: text
Content-Length: 1022
X-Lines: 29
Status: RO
Hans Henrik Happe wrote
> Is there a way to update the background of a MCC so that whatever
> MUIA_Background points to will be rendered as background?
>
> Pehaps a function like: UpdataBG(rport, x, y, width, height).
>
> I would like a way to update only parts of the background?
There is a private method in MUIs area class since muimaster.library V11
which will become public in future. You can start using it right now if
you want:
#define MUIM_DrawBackground 0x804238ca /* private */ /* V11 */
struct MUIP_DrawBackground { ULONG MethodID; LONG left; LONG top; LONG width; LONG height; LONG res1; LONG res2; LONG res3; }; /* private */
Together with MUIA_FillArea, FALSE, this allows custom background
control and optimized rendering without loosing MUIs background pattern
capabilities.
As always, left & top are *not* object relative. Be sure to supply a 0
for all three dummy vars for now, dont just omit them!
Of course, you may only call MUIM_DrawBackground inside your draw
method.
--
Greetings, Stefan
From: Gilles MASSON
To: mui@sunsite.Informatik.RWTH-Aachen.DE
Cc: masson@ogpsrv.unice.fr
Mime-Version: 1.0
Date: Mon, 13 May 96 16:01:42 +0200
Sender: masson@iut-soph.unice.fr
X-Mts: smtp
Resent-Message-Id: <"3UXeM1.0.cu1.F6qbn"@sunsite>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE
Subject: Unidentified subject!
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.DE
X-Mailing-List: archive/latest/1282
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE
X-Lines: 27
Status: RO
Content-Type: text/plain; charset="us-ascii"
Content-Length: 1173
The Area class attribute MUIA_Background is tell to get
same values as the MUIA_Image_Spec attribute, so can be:
- MUII_xxxx
- "0:" where is between MUII_BACKGROUND and
MUII_FILLBACK2 identifying a builtin pattern.
- "1:" where identifies a builtin standard image.
Don't use this, use "6:" instead.
- "2:,," where , and are 32-bit RGB
color values specified as 8-digit hex
string (e.g. 00000000 or ffffffff).
Kick 2.x users will get an empty image.
- "3:" where is the name of an external boopsi
image class.
- "4:" where is the name of an external MUI brush.
- "5:" where is the name of an external picture
file that should be loaded with datatypes.
Kick 2.x users will get an empty image.
- "6:" where is between MUII_WindowBack and
MUII_Count-1 identifying a preconfigured
image/background.
but is there a way to give them an BodyChunk or Image Object ?
Gilles MASSON
Subject: Re: Drag and Drop Methods
In-reply-to: Your message of "Thu, 06 Jun 96 06:08:14 PDT."
<31B6D83E.76F9@best.com>
Mime-Version: 1.0
Date: Thu, 06 Jun 96 16:20:20 +0200
Sender: masson@iut-soph.unice.fr
X-Mts: smtp
Resent-Message-ID: <"IIBIt3.0.wd6.qekjn"@susi>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.de
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.de
X-Mailing-List: archive/latest/1496
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.de
X-Lines: 24
Status: RO
Content-Type: text/plain; charset="us-ascii"
Content-Length: 980
> Hello, I need some more help, I have a program where I drag
> around objects and drop them with the D&D Methods. Everything works fine
> except for the fact that MUI reports the drop position based on the
> screen location of where it was dropped. The other problem is it bases
> the droped position based on where I grabbed it with the mouse, but I
> have know way of knowing where I grabbed the object at.
As it has been done, you should only consider the pointer position, and
not the grab object position.
> First is there some way I can get MUI to report the dropped
> position relative to the object that is accepting the drop? Also is
> there some way I can get mui to report based on the top, left of the
> object that was grabbed and not report from where you grabbed the object
> at?
If the position is screen based, just substract from it _mleft(obj) and
_window(obj)->LeftEdge, _mtop(obj and _window(obj)->TopEdge,
it should be ok.
Gilles MASSON
Subject: Re: Drag and Drop Methods
References: <199606070723.JAA02144@ogpsrv.unice.fr> <31B84977.6CD7@best.com> <31BD8791.5C0F@irz.inf.tu-dresden.de>
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"0ta76.0.1r.maQln"@susi>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.de
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.de
X-Mailing-List: archive/latest/1522
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.de
X-Lines: 37
Status: RO
Content-Type: text/plain; charset="us-ascii"
Content-Length: 1340
Sven Steiniger wrote:
>
> Brett Beebe wrote:
> >
> > Gilles MASSON wrote:
> > >
> > > > Ok, so you are saying I need to look at the start position when I begin
> > > > my drag, then look at the position when finished. Take the differance of
> > > > the two and +/- them from the original object position?
> > >
> > > I don't know what kind of D&D you're doing, all i know is that all
> > > standard MUI drops just look the pointer position to see where to
> > > insert the data/object, and not where is the currently moved image.
> > >
> > > Gilles MASSON
> >
> > Ok, I am dragging around ImageObjects, TextObjects, StringObjects. Along
> > with a whole bunch more stuff. So I really need to know where in the
> > object was grabbed. Thankx
>
> How can you drag StringObjects? Whenever I tried it either the
> StringObject gets activated or I have to drag the (very small) border.
> Have you found a solution?
>
> Thanks in advance,
> Sven.
First you need two mode of operation. One mode allows you to enter the
data in the string gadget. The other allows dragging. In the dragging
mode you make the StringObject a TextObject. That way you have no
problems dragging the objects around. You could also try making a Custom
string class.
But I am still trying to figure out where I grabbed the object at.
Any help out there?
From: "Kai Hofmann"
Date: Tue, 18 Jun 1996 15:11:09 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
X-Mailer: IntuiNews 1.3a (7.9.95)
Subject: Drag question
Message-ID: <60805954@informatik.uni-bremen.de>
Organization: Privat Amiga site
Resent-Message-ID: <"fki91.0.sL1.oGjnn"@susi>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.de
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.de
X-Mailing-List: archive/latest/1561
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.de
X-Lines: 21
Status: RO
Content-Type: text/plain; charset="iso-8859-1"
Content-Length: 879
Hi!
I am working on drag support for MonthNavigator.mcc, but it seems that it
is not possible to drag text objects that are in immediate mode - is there
any reason for this - or is it a bug?
I think its not a fault of mine, because the same code works perfectly for
text objects in relverify mode.
-------------------------------------------------------------------
Kai Hofmann EMail: i07m@zfn.uni-bremen.de
FB 3, Informatik i07m@informatik.uni-bremen.de
Universit=E4t Bremen WWW : http://www.informatik.uni-bremen.de/~i07m
IRC : PowerStat
-------------------------------------------------------------------
From: Allan
MIME-Version: 1.0
X-Mailer: Voodoo Demo 1.246 (Unregistered evaluation version)
In-Reply-To: <60805954@informatik.uni-bremen.de>
To: mui@sunsite.Informatik.RWTH-Aachen.de
Subject: Re: Drag question
Date: Wed, 19 Jun 1996 00:40:27 (+0100)
Content-Transfer-Encoding: 8bit
Resent-Message-ID: <"5MQ_n1.0.-_2.34pnn"@susi>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.de
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.de
X-Mailing-List: archive/latest/1565
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.de
X-Lines: 26
Status: RO
Content-Type: text/plain; charset="ISO-8859-1"
Content-Length: 1163
Hello Kai Hofmann, you're on the air with Dr.Love,
so speak your problem...
> I am working on drag support for MonthNavigator.mcc, but it seems that it
> is not possible to drag text objects that are in immediate mode - is
> there any reason for this - or is it a bug?
I can't answer the question of wether it's a bug or not, but I can give you a
way of making it work :)
Simply put every object you want draggable in its own draggable group, this
way you actually can drag objects which are in immediate mode... it
complicates things a little, but if you need the dragability, then that is
AFAIK the only way!
btw: Have a look at my project page, I'm doing a calender program which
features something that would probably be a nice thing to have in your
MonthNavigator.mcc (highlight holidays, link buttons to prev/next month!)
From: Brett Beebe
Organization: Personal
X-Mailer: Mozilla 2.0 (Win16; I)
MIME-Version: 1.0
To: mui@Susi.Informatik.RWTH-Aachen.de
Subject: Re: Drag question
References: <199606182243.AAA12279@Sunsite.Informatik.RWTH-Aachen.de>
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"_7VCs2.0.0J6.p40on"@susi>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.de
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.de
X-Mailing-List: archive/latest/1571
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.de
X-Lines: 27
Status: RO
Content-Type: text/plain; charset="us-ascii"
Content-Length: 1309
Allan wrote:
>
> Hello Kai Hofmann, you're on the air with Dr.Love,
> so speak your problem...
>
> > I am working on drag support for MonthNavigator.mcc, but it seems that it
> > is not possible to drag text objects that are in immediate mode - is
> > there any reason for this - or is it a bug?
>
> I can't answer the question of wether it's a bug or not, but I can give you a
> way of making it work :)
> Simply put every object you want draggable in its own draggable group, this
> way you actually can drag objects which are in immediate mode... it
> complicates things a little, but if you need the dragability, then that is
> AFAIK the only way!
There is another way. You need a custom layout hook, and a custom class
like a group class. You have two modes of operation, one is the
input mode where you can enter and input data, the other allows you to
drag around the objects. Now for every object you need to keep track of
it's x & y locations for your custom layout. I have code at home that
correctly calculates the new location based upon where the user grabbed
the object at. Remember me, I was the one that was asking the questions
about Drag and Drop. Well I was able to fix my problem, so if you would
like me to give you the code for the D&D that I have just let me know.
From: "Stefan Stuntz"
Date: Mon, 24 Jun 1996 19:23:39 +0100
X-Mailer: IntuiNews 1.3b Beta 7 (2.2.96)
Subject: Re: Problem with Drag-n-drop
Message-ID: <81322829@magic.informatik.tu-muenchen.de>
Organization: Home of MUI
Resent-Message-ID: <"Jj4QQ3.0._R6.Bikpn"@susi>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.de
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.de
X-Mailing-List: archive/latest/1628
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.de
Content-Type: text
Content-Length: 856
X-Lines: 27
Status: RO
KEIR JAMES (ugrad) wrote
> I've been trying to use the drag-n-drop (DND) facilities in a custom
> listview class. Everything seems to work OK except the dropmark functions.
>
> I need to know what line of the destination listview the dragged item is
> dropped on; I though I could use MUIA_List_DropMark but this always
> return 0.
Are you sure? The dragndrop demo uses something like this:
/*
** if we are in a sortable list (in our case the visible fields),
** we need to make sure to insert the new entry at the correct
** position. The MUIA_List_DropMark attribute is maintained
** by list class and shows us where we shall go after a drop.
*/
get(obj,MUIA_List_DropMark,&dropmark);
DoMethod(obj,MUIM_List_InsertSingle,entry,dropmark);
Note that you must get the dropmark from the destination
object, *not* form the source.
--
Greetings, Stefan
From: "Stefan Stuntz"
Date: Wed, 03 Jul 1996 11:38:28 +0100
X-Mailer: IntuiNews 1.3b Beta 7 (2.2.96)
Subject: Re: Drag problems ?
Message-Id: <81323229@magic.informatik.tu-muenchen.de>
Organization: Home of MUI
Resent-Message-ID: <"7-Ld13.0.PH7.w_Zsn"@susi>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.de
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.de
X-Mailing-List: archive/latest/1759
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.de
Content-Type: text
Content-Length: 637
X-Lines: 20
Status: RO
Gilles MASSON wrote in article <199607020945.LAA01593@ogpsrv.unice.fr>:
> When i set MUI_Draggable, TRUE to an object of my MUI_Area subclass,
> i don't receive anymore the SELECTUP (only the SELECTDOWN is still
> received).
> So is there anyway to know the a drag of the object has begun ?
Why?
> Another problem is that the drag begin as soon as i press the left
> button, whatever how the prefs for drag are set !
Whenever there are no conflicting inputs, MUI starts the drag operation
immediately. If the LMB is needed for anything else (ie on a button),
MUI starts dragging like specified in the prefs.
--
Greetings, Stefan